Learning to Solve Complex Planning Problems: Finding Useful Auxiliary Problems

Learning from past experience allows a problem solver to increase its solvability horizon from simple to complex problems. For planners, learning involves a training phase during which knowledge is extracted from simple problems. But how are these simple problems constructed? All current learning and problem solving systems require the user to provide the training set. However it is rarely easy to identify problems that are both simple and useful for learning, especially in complex applications. In this paper, we present our initial research towards the automated or semiautomated identification of these simple problems. From a difficult problem and a corresponding partially completed search episode, we extract auxiliary problems with which to train the learner. We motivate this overlooked issue, describe our approach, and illustrate it with examples. Introduction and Problem Formulation Researchers in Machine Learning and in Planning have developed several systems that use simple planning problems to learn how to solve more difficult problems (among several others, (Laird, Rosenbloom, & Newell 1986; DeJong & Mooney 1986; Minton 1988; Veloso & Carbonell 1993; Borrajo & Veloso 1994)). However, all current systems require that the simpler problems be provided by the user. This requirement is a gap in automated learning that we propose to fill. Using a previously untried approach, we are developing a system that will find auxiliary problems that are likely to be useful in learning how to solve a difficult problem. A planning problem can be considered difficult for a particular planner if it cannot solve the problem with a reasonable amount of effort. Learning how to solve difficult problems is a three-step process: First, the learner must find some simpler, i.e. more directly solvable, problems that are somehow related to the original problem. These problems are called auxiliary problems (Polya 1945). This first step is the one which we address here. Second, the learner must take these auxiliary problems and learn by solving them. Since they are simpler than the original problem, the planner should be able to solve the auxiliary problems with relatively little effort. Third, the learner must use the knowledge gained by solving the auxiliary problems to find a solution to the original problem. This process is successful if the time to carry out all three steps is significantly less than the time it would have taken to solve the original problem without the benefit of learning. Current learning systems work towards executing the second and third steps of the above process while finessing the first. Training problems from which to learn are usually generated randomly, entered by the user, or defined by a set of rules according to some preset measure of simplicity, such as number of goals, which is not necessarily accurate (Minton 1988; Etzioni 1993; Knoblock 1994; Bhansali 1991; Veloso 1992; Katukam & Kambhampati 1994). The goal of our research is to provide a general method for finding auxiliary problems that are most likely to help us learn how to approach a difficult problem. To be useful, these auxiliary problems must be solvable with relatively little effort on the part of the planner; otherwise they are no more approachable than the original problem. Yet the auxiliary problems must also retain some complexities, if only on a smaller, more learnable scale. If we simplify the problem too much we will not learn anything relevant to the original problem. Finding auxiliary problems that are neither too complex nor too simple is a difficult task. We believe that we will be able to accomplish this task because we are considering some available information that previous attempts at this task have ignored. Some of the few attempts at decomposing a problem into simpler problems are based on capturing different abstraction levels or problem spaces in the domain definition (Knoblock 1994; Rosenbloom, Newell, & Laird 1990; Sacerdoti 1974). These approaches have one thing in common: a static analysis of the domain and problem, either automated or done by the user. But simply looking at the problem may not provide any information as to what is causing the planner to have difficulty. We propose to examine not only the original problem and domain definition, but also the planner’s unsuccessful solution attempt. The partially completed search space from the original problem will help us discover why the problem is so hard for a particular planner. In this way, we will be able to determine what aspects of the original problem we most need to learn.